Design by contract Totally Explained

Everything about Design By Contract totally explained

Design by Contract, DbC or Programming by Contract is an approach to designing computer software. It prescribes that software designers should define precise verifiable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a business contract. Because Design by Contract is a registered trademark and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004. The current owner of these two trademarks is Interactive Software Engineering, Inc. Design by Contract has its roots in work on formal verification, formal specification and Hoare logic. The original contributions include:

A clear metaphor to guide the design process.
The application to inheritance, in particular a formalism for redefinition and dynamic binding.
The application to exception handling.
The connection with automatic software documentation.

Description

The central idea of DbC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" which defines for example that:

The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit).

The client must pay the fee (obligation) and is entitled to get the product (benefit).

Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts. Similarly, if a routine from a class in object-oriented programming provides a certain functionality, it may :

Impose a certain obligation to be guaranteed on entry by any client module that calls it: the routine's precondition — an obligation for the client, and a benefit for the supplier (the routine itself), as it frees it from having to handle cases outside of the precondition.

Guarantee a certain property on exit: the routine's postcondition — an obligation for the supplier, and obviously a benefit (the main benefit of calling the routine) for the client.

Maintain a certain property, assumed on entry and guaranteed on exit: the class invariant. The contract is the formalization of these obligations and benefits. One could summarize design by contract by the "three questions" that the designer must repeatedly ask:

What does it expect?

What does it guarantee?

What does it maintain? Many languages have facilities to make assertions like these. However, DbC is novel in recognizing that these contracts are so crucial to software correctness that they should be part of the design process. In effect, DbC advocates writing the assertions first.
The notion of a contract extends down to the method/procedure level; the contract for each method will normally contain the following pieces of information:

Acceptable and unacceptable input values or types, and their meanings

Return values or types, and their meanings

Error and exception conditions values or types, that can occur, and their meanings

Side effects

Preconditions, which subclasses may weaken (but not strengthen)

Postconditions, which subclasses may strengthen (but not weaken)

Invariants, which subclasses may strengthen (but not weaken)

(more rarely) Performance guarantees, for example for time or space used When using contracts, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with contract verification being the safety net. DbC's "fail hard" property makes debugging contract behavior much easier because the intended behaviour of each routine is clearly specified.
The contract conditions should never be violated in program execution; thus they can be either left in as debugging code or removed from the code altogether for performance reasons.
All class relationships are between Client classes and Supplier classes. A Client class is obliged to make calls to Supplier features where the resulting state of the Supplier isn't violated by the Client call. Subsequently, the Supplier is obliged to provide a return state and data that doesn't violate the state requirements of the Client. For instance, a Supplier data buffer may require that data is present in the buffer when a delete feature is called. Subsequently, the Supplier guarantees to the client that when a delete feature finishes its work, the data item will, indeed, be deleted from the buffer. Other Design Contracts are concepts of "Class Invariant". The Class Invariant guarantees (for the local class) that the state of the class will be maintained within specified tolerances at the end of each feature execution. Unit testing tests a module in isolation, to check that it meets its contract assuming its subcontractors meet theirs. Integration testing checks whether the various modules are working properly together. Design by Contract also fosters code reuse, since the contract for each piece of code is fully documented. The contracts for a module can also be regarded as a form of software documentation for the behavior of that module.

Non-technical analogy

A process in which a number of objects (people or software components, for example) interact to satisfy a goal is called a collaboration. When two objects collaborate together, one (the client) requests the services of the other (the supplier). The supplier in turn may request the services of other objects, and in those collaborations it's the client and they're the suppliers. The process only works correctly if all these individual collaborations work correctly. In a very real sense, the chain is only as strong as its weakest link.
Take the process of going on holiday, for example. Bertrand wants to spend two weeks in Florida. He books the holiday through DbC Holidays Inc., who specialise in U.S. package holidays. When he makes the booking (collaboration #1), Bertrand is the client and DbC Holidays are the supplier. DbC Holidays then arrange flights through Assertair Corp. (collaboration #2), and book a room at the Precondition Plaza Hotel in Miami (collaboration #3). In collaboration #2, DbC Holidays are the client and Assertair is the supplier, and in collaboration #3, the hotel is the supplier. And the chain of collaborations goes deeper and deeper (for example who does Assertair pay to service their jets?)
If any link in this chain of collaborations breaks, then the result could be that Bertrand's holiday is ruined. It's vital, therefore, that every player in the collaboration does what they're supposed to do. In any collaboration, client and supplier have certain obligations. These obligations (or "responsibilities", if you like) fall into three distinct types:

Things that the supplier promises to do as part of the service it offers to the client (for example Assertair promises DbC Holidays that Bertrand will be in Miami at a certain date and time)

Things that the client promises to do before using the service (for example DbC Holidays must ensure that Bertrand has his passport and tickets when he checks in for his flight)

Things that the supplier promises will always be true no matter what happens (for example The airline will always have adequate insurance to cover any accident) Things that the supplier promises to do as part of the service are described as a special kind of rule called a postcondition. The postcondition tells the client what will be true if the service is executed correctly (for example "your customer will be in Miami by 15:30 on June 8").
   If Bertrand turns up at the check-in desk without his passport, of course, then the airline can't live up to its side of the contract: he won't be allowed to board the plane without it. A rule that the client must satisfy before using a service is called a precondition.
   A rule that states what must always be true is called an invariant. If the airline doesn't have adequate insurance then nobody is going anywhere!
   Design By Contract is a discipline for building software such that the collaborations between objects are correct. A formula for correctness when a client uses the services of a supplier is given as:
If the invariant AND precondition are true before using the service, then the invariant AND the postcondition will be true after the service has been completed.
   In DbC, the responsibilities are clear: the client must satisfy the precondition. This distinguishes it markedly from a related practice known as defensive programming, where the supplier is responsible for figuring out what to do when a precondition is broken. More often than not, the supplier throws an exception to inform the client that the precondition has been broken, and in both cases - DbC and defensive programming - the client must figure out how to respond to that. DbC makes the supplier's job easier.

Language support

Languages with native support

Languages that implement most DbC features natively include:

Chrome

Cobra

Eiffel

Fortress

Lisaac

Nice

Sather

SPARK, via static analysis of Ada programs.

Spec#

Languages with third-party support

Various libraries, preprocessors and other tools have been developed for existing programming languages without native Design by Contract support:

C and C++, via the DBC for C preprocessor, GNU Nana, or the Digital Mars C++ compiler.

C#, via eXtensible C# (XC#).

Java, via iContract2, Contract4J

, jContractor

, Jcontract, C4J

, CodePro Analytix, STclass

, Jass preprocessor, OVal

with AspectJ, Java Modeling Language (JML), SpringContracts

for the Spring framework, or Modern Jass

, Custos

using AspectJ.

JavaScript, via Cerny.js

or ecmaDebug

Lisp

Common Lisp, via the macro facility or the CLOS metaobject protocol.
Scheme, via the PLT Scheme extension, emphasizing that each contract violation must blame the guilty party and must do so with an accurate explanation.(External Link)

Nemerle, via macros.

Perl, via the CPAN modules Class::Contract (by Damian Conway) or Carp::Datum (by Raphael Manfredi).

Python, via PyDBC or Contracts for Python.

Ruby, via Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

Generic tools

Perfect Developer, via the Perfect specification language, can verify contracts with static code analysis and generate programs in languages such as C++ and Java.Further Information

Get more info on 'Design By Contract'.

External Link Exchanges

Do you know how hard it is to get a link from a large encyclopaedia? Well we're different and will prove it. To get a link from us just add the following HTML to your site on a relevant page:

<a href="http://design_by_contract.totallyexplained.com">Design by contract Totally Explained</a>

Then simply click through this link from your web page. Our crawlers will verify your link, extract the title of your web page and instantly add a link back to it. If you like you can remove the words Totally Explained and embed the link in article text.
As long as your link remains in place, we'll keep our link to you right here. Please play fair - our crawlers are watching. Your site must be closely related to this one's topic. Any kind of spamming, dubious practises or removing the link will result in your link from us being dropped and, potentially, your whole site being banned.